Skip to content

Conversation

@DDShantanuBadmanji
Copy link

Delete this text and replace it with a detailed description of your change. The
PR title and body will become the squashed commit message.

If you would like to tag individuals, add some commentary, upload images, or
include other supplemental information that should not be part of the eventual
commit message, please use a separate comment.

If applicable, please include a summary of the testing strategy (including
rationale) for the proposed change. Unit and/or integration tests are expected
for any behavior change and system tests should be considered for larger
changes.

@coderabbitai
Copy link

coderabbitai bot commented Oct 1, 2025

Warning

Rate limit exceeded

@DDShantanuBadmanji has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 8 minutes and 17 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between ed79212 and 5989a26.

📒 Files selected for processing (13)
  • Vagrantfile (1 hunks)
  • clients/src/main/java/org/apache/kafka/common/config/AbstractConfig.java (4 hunks)
  • clients/src/main/java/org/apache/kafka/common/config/ConfigTransformer.java (3 hunks)
  • clients/src/main/java/org/apache/kafka/common/config/provider/ConfigProvider.java (1 hunks)
  • clients/src/test/java/org/apache/kafka/common/config/ConfigTransformerTest.java (5 hunks)
  • clients/src/test/java/org/apache/kafka/common/config/provider/MonitorableConfigProvider.java (1 hunks)
  • connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorMakerConfig.java (2 hunks)
  • connect/runtime/src/main/java/org/apache/kafka/connect/runtime/Worker.java (1 hunks)
  • connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerConfigTransformer.java (3 hunks)
  • connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/Plugins.java (3 hunks)
  • connect/runtime/src/test/java/org/apache/kafka/connect/runtime/WorkerConfigTransformerTest.java (5 hunks)
  • connect/runtime/src/test/java/org/apache/kafka/connect/runtime/WorkerTest.java (5 hunks)
  • connect/runtime/src/test/java/org/apache/kafka/connect/runtime/isolation/PluginsTest.java (4 hunks)
✨ Finishing touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch clone-KAFKA-18894

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@gemini-code-assist
Copy link

Summary of Changes

Hello @DDShantanuBadmanji, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a robust mechanism for monitoring Kafka's "ConfigProvider" implementations by integrating them with the "Monitorable" interface and wrapping them in a new "Plugin" object. This change significantly enhances the observability of custom configuration sources within Kafka Connect and other client components by allowing providers to expose metrics. The refactoring ensures that "ConfigProvider" instances are consistently managed and their metrics are properly registered with relevant tags, improving diagnostic capabilities and operational insights.

Highlights

  • Enhanced ConfigProvider Monitoring: ConfigProvider implementations can now expose metrics by implementing the "Monitorable" interface, allowing for better observability of custom configuration sources.
  • Standardized Plugin Wrapping: ConfigProvider instances are now consistently wrapped within a "Plugin" object across the codebase, centralizing their lifecycle management and metric registration.
  • Metrics Integration for Plugins: The "Plugins" class has been updated to facilitate the registration of metrics for Monitorable ConfigProviders, automatically adding relevant tags like "config", "class", and "provider".
  • Internal Refactoring: Core components like "AbstractConfig", "ConfigTransformer", and various Connect runtime classes have been refactored to work with the new "Plugin" type, ensuring seamless integration of the monitoring capabilities.
  • Comprehensive Test Coverage: New test cases and modifications to existing tests have been added to validate the correct instantiation, configuration, and metric reporting for MonitorableConfigProviders.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces a Plugin wrapper for ConfigProvider instances, which is a solid architectural improvement for enabling metrics via the Monitorable interface. The changes are consistently applied across the codebase, and new tests validate the metrics functionality. My review highlights a few minor inconsistencies in how the Plugin wrapper is instantiated, specifically regarding the tagging of metrics with the provider name. Addressing these will ensure consistent behavior as documented.

ConfigProvider provider = Utils.newInstance(entry.getValue(), ConfigProvider.class);
provider.configure(configProperties);
configProviderInstances.put(entry.getKey(), provider);
Plugin<ConfigProvider> providerPlugin = Plugin.wrapInstance(provider, null, CONFIG_PROVIDERS_CONFIG);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The new Javadoc for ConfigProvider states that a provider tag will be automatically added to all registered metrics. However, this Plugin.wrapInstance call does not include the provider name as a tag. This is inconsistent with other parts of the code, such as in connect.runtime.isolation.Plugins, and with the documented behavior. To ensure metrics are tagged correctly, you should add the provider name tag.

Suggested change
Plugin<ConfigProvider> providerPlugin = Plugin.wrapInstance(provider, null, CONFIG_PROVIDERS_CONFIG);
Plugin<ConfigProvider> providerPlugin = Plugin.wrapInstance(provider, null, CONFIG_PROVIDERS_CONFIG, Map.of("provider", entry.getKey()));

@BeforeEach
public void setup() {
configTransformer = new ConfigTransformer(Collections.singletonMap("test", new TestConfigProvider()));
configTransformer = new ConfigTransformer(Map.of("test", Plugin.wrapInstance(new TestConfigProvider(), null, "config.providers")));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The Plugin wrapper for the TestConfigProvider is missing the provider tag for metrics. For consistency with the documented behavior and production code, the provider name ("test") should be included as a tag. This ensures that if this test provider were to register metrics, they would be tagged correctly.

Suggested change
configTransformer = new ConfigTransformer(Map.of("test", Plugin.wrapInstance(new TestConfigProvider(), null, "config.providers")));
configTransformer = new ConfigTransformer(Map.of("test", Plugin.wrapInstance(new TestConfigProvider(), null, "config.providers", Map.of("provider", "test"))));

@BeforeEach
public void setup() {
configTransformer = new WorkerConfigTransformer(worker, Collections.singletonMap("test", new TestConfigProvider()));
configTransformer = new WorkerConfigTransformer(worker, Map.of("test", Plugin.wrapInstance(new TestConfigProvider(), null, "config.providers")));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The Plugin wrapper for the TestConfigProvider is missing the provider tag for metrics. For consistency with the documented behavior and production code, the provider name ("test") should be included as a tag. This ensures that if this test provider were to register metrics, they would be tagged correctly.

Suggested change
configTransformer = new WorkerConfigTransformer(worker, Map.of("test", Plugin.wrapInstance(new TestConfigProvider(), null, "config.providers")));
configTransformer = new WorkerConfigTransformer(worker, Map.of("test", Plugin.wrapInstance(new TestConfigProvider(), null, "config.providers", Map.of("provider", "test"))));

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants